In order to constitute standard specifications for implementing personal information and enterprise data synchronization among multiple platforms and networks, many companies like IBM, Nokia, Palm, Psion, etc., created an industry organization, SyncML iniative, in February 2002. The object of developing the SyncML is to make terminal users, device developers, fundamental component developers, data providers, application software providers and service providers to cooperate together and to make it possible to use any terminal device to visit any network data at any time and any place. A typical application of a SyncML data synchronization is the data synchronization between a network Server and a mobile device or an application Server. Besides, SyncML can also be used for an equivalent data synchronization, e.g. between two PCs.
Clients and Servers mentioned herein all support the SyncML technique, so all the SyncML Clients and SyncML Servers are shortened as Clients and Servers thereafter.
FIG. 1 is a schematic diagram illustrating a procedure of transmitting the SyncML synchronization data in the related art.
Step 101˜step 102: the Client initiates a synchronization initialization request to the Server, requesting an authentication by the Server; the synchronization initialization request usually contains authentication information and device capability information of its own, wherein the authentication information usually contains a user name and a password; the Server executes the initialization operation after receiving the authentication request, and returns an authentication result as well as device capability information of the Server, then the Client executes the initialization operation according to the device capability information of the Server. The initialization is thus finished. The above-described initialization comprises operations of authenticating the user information, designating database(s) to be synchronized, etc.
Of course, if the synchronization initialization request sent to the Server by the Client does not include the authentication information or the device capability information, the Server may request the Client to transmit the required information again.
The above steps constitute the initialization phase of the whole synchronization session by mutual authentication and negotiate the device capabilities of both sides, e.g. supported synchronization types, databases, etc., and to negotiate the database(s) to be synchronized.
Step 103˜step 104: the Client sends a synchronization package to the Server, which includes the data to be synchronized. The Server synchronizes the data after receiving the synchronization package and then sends another synchronization package to the Client, which includes a response and the data of the Server to be synchronized.
The Client synchronizes the data after receiving the synchronization package from the Server; if there is still unprocessed data to be synchronized afterward, step 103 and step 104 are repeatedly executed until all data to be synchronized is processed.
The above-described steps constitute the synchronization phase of the whole synchronization session by exchanging synchronization package between the Client and the Server.
Step 105˜step 106: the Client sends to the Server a synchronization completion request, and the Server returns an acknowledgement to confirm that the synchronization session is finished successfully.
Thus it is not difficult to see that, the existing method for transmitting the SyncML synchronization data has the following disadvantages:                1) The method that the Client sends the authentication information is unsafe, a third party can easily intercept it. The reason is: if transmitted in clear text, the information can be obtained immediately after being intercepted; if transmitted in the BASE64 encoded mode, the information can be easily decrypted after being intercepted; and it is similar with the MD5 mode (It was proved that the attacker could find MD5-collisions to make the MD5 unsafe in the International Cryptology Conference held in August 2004 in California, US), therefore, the transmission is not very safe even if the MD5 mode is adopted.        2) There is no protection on the user's most important private data, i.e. the data to be synchronized.        3) There is no protection on the data in the transport layer.        